The present disclosure relates generally to information networks and, more particularly, to computer systems and computer-based methods for enriching merchant identifiers associated with requests for updated cardholder account data.
A payment card is a cashless payment device that may be embodied, for example, as a credit card, debit card, contactless RFID-enabled device including a smart card, Near-Field Communication enabled smartphone, electronic mobile wallet or the like. The payment card may be a device, real or virtual, by which the cardholder, as payer and/or source of funds for the payment, may be identified.
A payment card may be presented by a cardholder for transacting a payment at a point of sale or from a remote location. In some instances, individuals may repeatedly transact transactions with a single merchant, such as a repeat customer or by way of recurring payments. A repeat transaction may be triggered at regularly scheduled intervals or upon occurrence of an event, for example, the balance reaching a predetermined threshold.
It has become common for individuals to enroll with merchants with whom they expect to have repeat transactions for goods and services using a payment card. Once enrolled, when making a transaction, the individual need not reenter personal data and payment card data. Instead, the merchant may attempt to complete a transaction using the already submitted personal and payment card data. These transactions are known as “card-not-present” (CNP) transactions. In such transactions, data regarding the payment card, including a personal account number (PAN) and, in many instances, an expiration date for the payment card is transmitted from a merchant, along with an indicator that the transaction is a CNP transaction. An “account-on-file” transaction is another type of transaction in which the merchant stores data regarding the cardholder's payment card in a database, then retrieves the stored payment card data and includes it in a payment authorization request. One specific type of account-on-file transaction is a “recurring payment transaction,” which a merchant initiates on a recurring basis for a particular cardholder. In such recurring payment transactions, the merchant stores data regarding the cardholder's payment card in a database, then retrieves the stored payment card data and includes it in each recurring authorization request.
An example of a recurring card-on-file payment transaction is a gym membership. Rather than mailing a monthly check for membership with a gym, a cardholder might choose to register a payment card, such as a credit card, a debit card, or a prepaid card, with the gym. Registering the payment card with the gym enables the gym to automatically charge the payment card for the monthly dues on a particular day each month. In some such systems, the merchant stores a PAN, an expiration date, and/or other data associated with the payment card and/or cardholder. Given the convenience of this payment model for both merchants and cardholders, it finds use in many other scenarios where a cardholder is a member of a club or subscriber of products or services. Accordingly, multiple merchants may have stored payment card data for the same cardholder. Likewise, any given merchant may have stored payment card data for multiple cardholders.
During an authentication phase of a transaction, the personal account data may be used by authenticating entities to authenticate the transaction. Entities involved in the authentication process may include, for example, the issuing bank that issued the payment card to the cardholder, the merchant, and/or the merchant bank that authorizes payment card transaction and transfers money on behalf of the merchant. These activities may be coordinated by a credit card payment system including a payment processor. In some instances, the issuing bank and the merchant bank compare personal account data associated with the cardholder for verification purposes before authorizing the transaction. However, when the personal account data stored by the issuing bank and the merchant bank do not match, such as due to an update of personal account data with only one of the authenticating entities, the transaction may be denied.
When a cardholder's personal account data changes, transactions may be denied unless updates are shared with each authentication entity. The process for updating personal account data can be tedious and time consuming. What is more, the updating process may be performed haphazardly since individuals do not typically have a comprehensive list of parties that they have enrolled with for future or recurring transactions. Missing an update may cause denial of an important payment, potentially causing further complications and penalty fees.
To prevent these interruptions, merchants may submit requests for cardholder account data updates directly to the payment card payment system associated with the payment card. Ideally, enabled cardholders would have control over whether or not such a request is granted or denied. However, the request may contain non-enriched merchant identifiers that may obfuscate or otherwise render unrecognizable the identity of the merchant to a cardholder. Thus, a cardholder would be unable to make an informed decision whether to grant or deny the request. There is therefore a need to enrich merchant identifiers associated with requests for updated cardholder account data so as to make the identity of the requesting merchant more obvious to cardholders.